跟身邊大部份朋友比起來，筆者出社會以前，在學校待的時間算是比較久的，也在一些不同國家擔任過研究生與研究助理。在「某些國家」的學術機構，研究員與教授們有一項很重要的工作：「做國科會專案」。國科會專案有大有小，有些會橫跨好幾年，但不論大小，都有一個很重要的任務要做：「報告進度」。例如，你與幾位教授合作爭取到了一個為期三年的超大型研究專案，三年後會有一個預期成果。然而在這期間也不是就放牛吃草了，為了確保三年後的成果能夠實現，每間實驗室每年都得有個階段性成果發表，甚至為了這個成果發表，有些單位還會每季，甚至每個月都舉辦小型發表會，以確保大家每個月、每季、每年都走在正確的道路上。
「某些國家」的故事，聽起來很美好，對吧？
但事實上，出社會多年後再回頭看，一個三年的計畫，如果在第一天就規定好最後一天的具體成果，那麼在這個研究計畫到時候就肯定會「成功」。為什麼？因為大家都很聰明，他們肯定會努力做好自己的研究，然後在最後要成果發表的那一天，把自己的研究成果「轉型」成計畫描述的樣子，貼心地為評審委員找好給過的理由，評審委員覺得合理，給過就過了。既然一開始就注定了最終結局，那麼中間的階段性成果發表是不是這麼重要，我想答案也呼之欲出了。焦論如何，如此一番操作下來，國科會有教授執行研究計畫，教授有經費進行自己擅長的學術研究，這些研究不管是不是真的跟當初的計劃緊密結合也不要緊，反正肯定是個對人類未來科技有幫助的科學研究。
你看，這下大家開開心心的，皆大歡喜，多好！
然而，有在社會上打滾的人都知道，真實的業界很難遇到這麼好的事。這個社會天天都在變，流行與趨勢也是一陣一陣都不同，如果現在你要訂一個三年後的計畫，那麼很可能三年後你會發現這些東西已經有很多人都做過，或甚至是早已流行完畢，大家已經在做別的事了。
此時，就算你真的能做到三年前的目標，又能如何？
當然也許你能找出一些堅持努力最後成功的案例，但，你是否就是那條龍，這，我們都不知道。擁有一個遠大的目標很重要，也很可貴，但眼下活下來，才能確保自己能撐到變身成為那條龍的一天，這也是很重要的。
我想說的其實是，你的目標是一個東西、一個數據，還是一種價值的實現？這是全然不同的思維。
2019 年一個未知的病毒席捲全球，中華民國自由地區（a.k.a. 台灣 a.k.a. 中華台北）雖相對其他國家情況好很多，但還是終究遇到了疫情擴散的一天。數據告訴我們，物理的隔離是經濟有效的方法，口罩就是其中之一。面對這個未知又可怕的病毒，中央與地方都想盡辦法要讓民眾方便取得口罩。中央的方法是健保卡過卡加藥劑師人力分裝的士砲方法（當然後來流程與通路都有更新好幾次就是了），台北市政府的方法則是先進、幾乎零接觸的「口罩販賣機」。乍看之下台北市的 Solution 先進衛生又經濟，光比技術含量應該是要屌打中央的人力密集的土砲方法的，但事實呢？
據記錄，中央在2020年1月底宣布禁止出口口罩，幾天後徵用口罩，2 月初開始執行口罩實名制的第一版本，而在其後又陸陸續續因流程優化與配合資源到位，前前後後改版了幾次。
而口罩販賣機則是因為機型、設點、招標不順等因素，在 3 個月後，也就是同年 4 月開始啟用。同年 8 月，適逢中央推出口罩3.0，民眾取得口罩更加容易，且國內疫情狀況趨緩，需求量也下降，台北市政府決定將口罩販賣機退場。此時全台北市的口罩販賣機也只有 6 台而已。
為什麼？當然原因很多，不能一概而論，但筆者從目標來看，會認為中央與地方的「目標」，從一開始就不一樣。大家開始針對口罩分配這件事想辦法，都是在 2020 年初，起跑時間相同，但台北市一開始就把目標設在「如何讓口罩販賣機快點上線」，而於此同時，中央的目標則是「如何把公平地把每天生產的口罩快點發出去」。
我們都知道，敏捷開發講求的是「快速適應，提高價值」。如果上面這個例子是一個軟體產品的開發過程，你一開始就把目標鎖定在迭代較慢的方法上，雖然技術含量較高，萬一價值未能提升，再回頭是需要勇氣的。更何況人心是肉做的，付出的「沉沒成本」一高，果斷回頭就更難了。
口罩也一樣，軟體開發也一樣，筆者認為，早日體現的終端產品價值與真實用戶回饋，要勝過全盤而縝密的計劃。
然而，有些讀者看到這裡已經坐不住了：「你們這些敏捷教徒總是這樣，做事莽莽撞撞，沒有計劃怎麼知道要努力什麼？」
誤會大了！敏捷開發要我們專注於提升價值，可從來沒叫我們「不要計劃」！
在軟體開發過程中，Coding 與 Testing 需要成本、需要時間，計劃也是一樣；丟棄的 Coding 與 Testing 是一種浪費，計劃也是一樣。如果我們能像神一樣，打從一開始就能考慮到未來所有會發生事情的細節，那當然沒有問題。然而我們不是神，我們可以藉資料、理論、經驗等工具輔助，來提高預測的準確度，但沒人能保證任何預測能 100% 準確。如果有也不叫預測了，叫通靈。於是，有兩件事在生產過程中就變得很重要了：
如果能做到上面兩點，那付出的總成本就可控，自然就能更「快速」地，一步步調整做法，並藉此慢慢提高價值。經驗在這過程中是必要的，這是一個 Empirical Process。
回到本段一開始說的，我不是叫你不要計劃，一如在開發軟體時，也沒人叫你不要設計，現代的軟體開發，講求的是不要「過度設計」。請記得：「提前計劃」跟「過度設計」是兩件事。有一件事你知道它一定會發生，或已經決定了會在某個時間點發生，那為此提前計劃並穩步前行是很正常的。但如果這件事只是感覺可能發生，那為些預留彈性，就很有可能造成浪費了。
讀者不妨自已回憶一下，上次你為了一個老闆沒說、客戶沒要，但你自己覺得這功能未來應該會需要而先做好了，而幾個月後老闆客戶也真的跟你要了，於是你驕傲地馬上回答：「我早就想到並做好了！」的經驗是在多久以前？
各位讀者怎麼我不確定，筆者自己從未遇過就是了。
Kent Beck 在 Extreme Programming 一書中告訴我們，不要過度規劃，意思是還不知道的事，不要做沒有依據的假設，也不要預留不一定用得到的彈性空間，這些都是浪費。
謎之聲：「知之為知之，不知為不知，是知也。」
iThome鐵人賽
看影片追技術